Skip to main content

Interoperability Maturity Model

A maturity model is a diagnostic, not a scorecard. Its value is in showing that an ecosystem is at level 3 for terminology and level 1 for governance — because that gap, not the average, is what determines what happens next.

This model is offered as a working instrument for assessment and planning. It is a Tier 3 (educational) construct synthesised from established practice, not a normative standard. Where a formal assessment is needed, WHO's Digital Implementation Investment Guide and the Global Digital Health Monitor provide externally validated instruments.


The levels​

Level 0 — Siloed​

Systems exist and do not exchange. Data moves by re-keying, spreadsheets and paper. Each system has its own patient list, its own facility list and its own codes.

Typical symptom: the same indicator has three different values depending on which system produced it, and nobody can explain why.

Level 1 — Basic integration​

Point-to-point interfaces exist between a few systems, built bespoke, usually by whichever vendor was available. They work, and each one is maintained separately.

Typical symptom: adding a system means building N new interfaces, and the integration budget is growing faster than the system budget.

Level 2 — Standards-based exchange​

Exchange uses published standards — FHIR, HL7 v2 — through a shared interoperability layer. Systems integrate once.

Typical symptom: messages flow reliably and the receiving systems still cannot pool the data, because codes and identifiers do not align. This is where most programmes are, and where the plateau is longest.

Level 3 — Semantic interoperability​

Shared registries resolve identity. Shared terminology gives codes a common meaning. National profiles constrain the standards. Data from different sources can be pooled and analysed together.

Typical symptom: the data is genuinely usable, and the constraint has moved to governance and operations.

Level 4 — National shared services​

A functioning health information exchange with shared services — registries, terminology, consent, a shared health record — governed and operated as national infrastructure, with a sustainable funding model. New systems join through a defined onboarding and conformance process.

Typical symptom: the exchange is boring, which is the objective.

Level 5 — Data-driven and AI-enabled​

The ecosystem uses its own data routinely for decision support, quality improvement, surveillance and planning. Computable guidelines are deployed and maintained. AI is used under governance, with monitoring and stopping rules. Feedback loops from outcomes to practice exist.

Typical symptom: changes to clinical guidance propagate to the point of care in weeks rather than years.

Level 5 is not a destination for most systems, and pursuing it before level 3 is the most common strategic error in this field. AI over data that cannot be pooled produces confident nonsense.


The dimensions​

Assess each independently. The lowest dimensions constrain the whole.

DimensionL0L1L2L3L4L5
GovernanceNoneProject-basedStandards namedArchitecture board with authoritySustained institution, fundedIncludes AI oversight, evidence loops
IdentityLocal IDs onlySome cross-referencingShared ID definedClient registry operating, quality measuredUniversal, high match rate, merges handledIdentity supports research and linkage under governance
InteroperabilityManualPoint-to-pointStandards via a layerProfiled, conformance-testedOnboarding process, certificationReal-time, event-driven where needed
TerminologyFree text / local codesSome codingStandard code systems in useTerminology service, governed value setsNational extension maintained; maps versionedTerminology drives decision support and analytics
Data qualityUnknownAnecdotalSome checksMeasured and publishedAccountable, improvingQuality feeds back automatically
SecurityAd hocBasic controlsPolicy existsControls implemented and auditedCertified, tested, rehearsedContinuous monitoring, anomaly detection
Privacy and consentUndefinedPolicy on paperLegal basis establishedConsent service operatingPatient-visible, withdrawal worksGranular, purpose-based, enforced
InfrastructureAd hocServers existManaged hostingAvailability targets metTiered, DR rehearsedElastic, observable, self-healing
AnalyticsPaper reportsSpreadsheetsHMIS operatingIndividual-level analysis possibleIntegrated, definitions sharedPredictive, embedded in workflow
WorkforceNo specialist capacityIndividual championsSome trained staffDefined roles, retentionCareer paths, institutional capacityContinuous capability development
AINoneExperimentsPilots without governanceInventory and governance existDeployed with monitoringGoverned lifecycle with stopping rules

Using it​

Assess honestly. The instinct is to score aspirationally — "we have a client registry" when it exists but holds no data, or "governance exists" when a committee met twice. Score on operating reality: is it running, is it used, is anyone accountable?

Useful evidence questions per dimension:

  • Identity: what is the measured duplicate rate, and who works the review queue?
  • Terminology: when was the last value set release, and who authorised it?
  • Governance: name a procurement the board changed or stopped.
  • Data quality: show the published metrics by facility.
  • Security: when was the last tested restore?

Each of those is answerable with evidence or not at all, which is the point.

Read the gaps, not the average. An ecosystem at 4 for infrastructure and 1 for governance is not "at level 2.5". It has built infrastructure it cannot govern, and the next investment should be governance.

The lowest dimension is the constraint. Advancing a high dimension further delivers little while a low one blocks. This is the model's main practical use.


Advancing a level​

What actually moves each transition — and note how little of it is software:

TransitionWhat it takes
0 → 1A single working interface with a real user; demonstrates the value
1 → 2An interoperability layer, a named standard, and the discipline to route new integrations through it
2 → 3Registries and terminology. The longest and least glamorous transition, and the one most often skipped
3 → 4Institutionalisation: sustained funding, an operating team, onboarding and conformance processes, governance with authority
4 → 5Computable guidelines, analytics embedded in workflow, AI governance, feedback loops from outcome to practice

The 2 → 3 transition is where programmes stall for years. It is unglamorous, requires clinical and terminology expertise rather than engineering, produces no demonstrable feature, and is the precondition for everything above it.


A pragmatic assessment exercise​

Half a day, with the right people in the room:

  1. Score each dimension 0–5, with evidence required for each score
  2. Identify the two lowest dimensions
  3. Ask what specifically blocks advancing each by one level
  4. Check whether the current investment plan addresses those blockers
  5. If it does not, that is the finding

Repeat annually. The trajectory matters more than the absolute score.


Other assessment instruments​

InstrumentFocus
Global Digital Health MonitorCountry-level digital health maturity across several categories — https://monitor.digitalhealthmonitor.org/
WHO Digital Implementation Investment GuideInvestment planning, with maturity implicit — https://www.who.int/publications/i/item/9789240010567
Digital Square global goods maturity modelMaturity of individual software products, not ecosystems — https://globalgoodsguidebook.org/
HIMSS maturity modelsFacility-level EMR adoption; hospital-oriented, and commercially assessed

Use an external instrument where comparability or funding requires it. Use this one internally, where honesty is more useful than comparability.


References​